DRAIN_EXCLUSIVE_ACTIONS implementation #1355

steve-the-edwards · 2025-06-20T20:25:31Z

Add an option to get the next action that is mutually exclusive to the dirty nodes. Then we can apply as many of those actions as possible.

Add tests for this as well and ensure existing tests can run with this runtime config on.

zach-klippenstein

I don't understand the interaction between conflation and drainExclusive. It looks like we run the drainExclusive loop first, then render, then conflate, drainExclusive, and render, etc. Wouldn't we want to continuously interleave drainExclusive and conflation passes? Or is that what we're doing and I just can't read code?

zach-klippenstein · 2025-06-23T23:20:57Z

workflow-runtime/src/commonMain/kotlin/com/squareup/workflow1/WorkflowInterceptor.kt

  ): Unit = Unit

-  public sealed interface RuntimeLoopOutcome
+  public sealed interface RuntimeUpdate


At the risk of over-optimizing, this could be a value class to avoid allocating RenderingProduced objects every pass even when they're ignored.

nice. will take a look at doing this.

I'd have to talk more with you about what you are thinking. I am not sure we even need to report the rendering itself to the interceptor. I can start by just removing that?

Well, that object is already allocated (probably why I was not worried originally). So we could start by just making RenderingProduced a value class I think I was confused originally because this comment was on the RuntimeUpdate sealed interface

I made RenderingProduced a value class now. The others are just objects, so this should all be quite fast / have minimal allocations.

There's no point in making a subclass of this a value class, since it will be boxed when referred to as a parent type. We'd need to replace the entire sealed class/interface hierarchy with a single value class.

Oh, interesting!

zach-klippenstein · 2025-06-23T23:27:04Z

workflow-runtime/src/commonTest/kotlin/com/squareup/workflow1/RenderWorkflowInTest.kt

+  }
+
+  @Test
+  fun `for_drain_exclusive_and_render_only_when_state_changes_we_handle_multiple_actions_in_one_render_but_we_do_pass_rendering_if_state_changed_earlier`() {


Nit: You shouldn't need the backticks here, you're not using spaces or other illegal characters.

It's actually because this is KMP code that runs on js as well, IIRC. For some reason the kotlin-js compiler can't handle long names that don't have ticks? Or maybe that's why I had to add the _. Now I can't remember. But it was something with kotlin-js.

Turns out I was just remembering wrong or had copied this forward when not needed. Removed now!

steve-the-edwards · 2025-07-03T19:54:20Z

I don't understand the interaction between conflation and drainExclusive. It looks like we run the drainExclusive loop first, then render, then conflate, drainExclusive, and render, etc. Wouldn't we want to continuously interleave drainExclusive and conflation passes? Or is that what we're doing and I just can't read code?

the main loop (after the first synchronous render) is:

awaitAndApplyAction() for the first available action
DEA loop: Drain any exclusive actions immediately available - synchronously for any actions already queued (no suspend here).
render()
CSR loop: Drain any other actions immediately available; render() after each one.
pass updated rendering down the StateFlow.

No interleaving is necessary from what I can tell. The exclusive actions for DEA are just a subset of the actions that can be applied without rendering at all.

mannydelgado · 2025-07-07T15:04:57Z

workflow-runtime/src/commonMain/kotlin/com/squareup/workflow1/internal/WorkflowNode.kt

@@ -281,7 +296,7 @@ internal class WorkflowNode<PropsT, StateT, OutputT, RenderingT>(

    if (!runtimeConfig.contains(PARTIAL_TREE_RENDERING) ||
      !lastRendering.isInitialized ||
-      subtreeStateDidChange
+      subtreeStateDirty


Should we be checking the selfStateDirty here as well?
is there in which the self state might be dirty but the subtree isnt?

no. if self is dirty, subtree is also dirty. Not true the other way around though, subtree may be dirty without the self being dirty.

Subtree includes self, basically.

rjrjr · 2025-07-07T16:04:05Z

I don't understand the interaction between conflation and drainExclusive. It looks like we run the drainExclusive loop first, then render, then conflate, drainExclusive, and render, etc. Wouldn't we want to continuously interleave drainExclusive and conflation passes? Or is that what we're doing and I just can't read code?

the main loop (after the first synchronous render) is:

awaitAndApplyAction() for the first available action

DEA loop: Drain any exclusive actions immediately available - synchronously for any actions already queued (no suspend here).

render()

CSR loop: Drain any other actions immediately available; render() after each one.

pass updated rendering down the StateFlow.

No interleaving is necessary from what I can tell. The exclusive actions for DEA are just a subset of the actions that can be applied without rendering at all.

It'd be good to capture this in a comment in the code.

zach-klippenstein · 2025-07-07T18:21:25Z

I don't understand the interaction between conflation and drainExclusive. It looks like we run the drainExclusive loop first, then render, then conflate, drainExclusive, and render, etc. Wouldn't we want to continuously interleave drainExclusive and conflation passes? Or is that what we're doing and I just can't read code?

the main loop (after the first synchronous render) is:

awaitAndApplyAction() for the first available action

DEA loop: Drain any exclusive actions immediately available - synchronously for any actions already queued (no suspend here).

render()

CSR loop: Drain any other actions immediately available; render() after each one.

pass updated rendering down the StateFlow.

No interleaving is necessary from what I can tell. The exclusive actions for DEA are just a subset of the actions that can be applied without rendering at all.

Why would exclusive actions only be available after (1) and not after (3)?

steve-the-edwards · 2025-07-07T20:19:24Z

I don't understand the interaction between conflation and drainExclusive. It looks like we run the drainExclusive loop first, then render, then conflate, drainExclusive, and render, etc. Wouldn't we want to continuously interleave drainExclusive and conflation passes? Or is that what we're doing and I just can't read code?

the main loop (after the first synchronous render) is:

awaitAndApplyAction() for the first available action

DEA loop: Drain any exclusive actions immediately available - synchronously for any actions already queued (no suspend here).

render()

CSR loop: Drain any other actions immediately available; render() after each one.

pass updated rendering down the StateFlow.

No interleaving is necessary from what I can tell. The exclusive actions for DEA are just a subset of the actions that can be applied without rendering at all.

Why would exclusive actions only be available after (1) and not after (3)?

We chatted offline and realized I need to make a few things much more clear in the code:

we only have new actions to process when we suspend which only happens with 1 .
the DEA loop will do nothing when using an immediate dispatcher where the select will return 'immediately' after the first action is available. We need to use a fairer dispatcher to get multiple actions to drain.
We don't need to run the DEA loop after 4 (after CSR action handling) again because there was no suspension there so there are no new DEA actions ready to be processed.

steve-the-edwards force-pushed the sedwards/dea-2-for-real branch 4 times, most recently from b276a5b to eefc6d8 Compare June 20, 2025 20:56

steve-the-edwards marked this pull request as ready for review June 20, 2025 20:57

steve-the-edwards requested review from zach-klippenstein and a team as code owners June 20, 2025 20:57

steve-the-edwards mentioned this pull request Jun 20, 2025

DRAIN_EXCLUSIVE_ACTIONS implementation #1269

Closed

zach-klippenstein reviewed Jun 23, 2025

View reviewed changes

steve-the-edwards force-pushed the sedwards/dea-2-for-real branch from e6b2344 to 1551901 Compare June 24, 2025 14:18

steve-the-edwards force-pushed the sedwards/dea-2 branch from f116b2d to f38b27a Compare July 3, 2025 14:23

steve-the-edwards requested a review from a team as a code owner July 3, 2025 14:23

steve-the-edwards force-pushed the sedwards/dea-2 branch 2 times, most recently from 5b45b9a to 44397aa Compare July 3, 2025 19:24

steve-the-edwards force-pushed the sedwards/dea-2-for-real branch 2 times, most recently from 9a60fe3 to 0acd80d Compare July 3, 2025 19:44

steve-the-edwards force-pushed the sedwards/dea-2 branch from 4f4977a to a3bf0ad Compare July 3, 2025 19:45

steve-the-edwards force-pushed the sedwards/dea-2-for-real branch from 0acd80d to 4d41e92 Compare July 3, 2025 19:47

steve-the-edwards requested a review from zach-klippenstein July 3, 2025 20:11

Base automatically changed from sedwards/dea-2 to main July 3, 2025 20:56

steve-the-edwards force-pushed the sedwards/dea-2-for-real branch 2 times, most recently from b0dfc9c to 3635e7d Compare July 4, 2025 14:38

mannydelgado reviewed Jul 7, 2025

View reviewed changes

rjrjr approved these changes Jul 7, 2025

View reviewed changes

steve-the-edwards force-pushed the sedwards/dea-2-for-real branch 2 times, most recently from 83c12df to 176b598 Compare July 9, 2025 20:32

steve-the-edwards mentioned this pull request Jul 10, 2025

Use WorkStealingDispatcher in runtime, behind a flag. #1365

Open

DRAIN_EXCLUSIVE_ACTIONS implementation

e48d80e

steve-the-edwards force-pushed the sedwards/dea-2-for-real branch from 176b598 to e48d80e Compare July 11, 2025 14:28

steve-the-edwards merged commit 7285d9a into main Jul 11, 2025
64 checks passed

steve-the-edwards deleted the sedwards/dea-2-for-real branch July 11, 2025 15:22

DRAIN_EXCLUSIVE_ACTIONS implementation #1355

DRAIN_EXCLUSIVE_ACTIONS implementation #1355

Conversation

steve-the-edwards commented Jun 20, 2025

Uh oh!

zach-klippenstein left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

steve-the-edwards Jul 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

steve-the-edwards commented Jul 3, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rjrjr commented Jul 7, 2025

Uh oh!

zach-klippenstein commented Jul 7, 2025

Uh oh!

steve-the-edwards commented Jul 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

steve-the-edwards Jul 4, 2025 •

edited

Loading

steve-the-edwards commented Jul 7, 2025 •

edited

Loading